\section{Results}\label{results}
We have examined the legal implications of developing software for
safety-critical systems and deduced constraints on software processes in
accordance to these implications. In order for an organization to develop 
software prudently for use in safety-critical environments, they must engage in
certain activities. We describe one such activity: the commenting practices of
software developers.

In addition, we have designed the requirements for a system that will help
organizations fulfill some of the legal constraints for software organizations
in the safety-critical realm. If a system that implements our design were in
place, an organization will be able to provide adequate documentation of design
decisions during the software development process. Our system allows for 
software developers to easily write versioned, multiple-code-associated comments
in real-time without severely disrupting the  development process or impeding
the readability of the code base.

\subsection{Drawbacks}

\subsubsection*{Documentation Attitude}
The success of this system requires a forward-thinking attitude of commitment to
documentation. Most domains of software engineering spend minimal time with
formal documentation methods in an effort to achieve faster turnaround and
short-term gain through quick (and often rushed) implementation cycles. This
atittutde for fast turnaround and quicker profits ultimately hurts not only our
solution, but safety-critical software systems in general. Since academia is not
safety-critical, many students are not learning the most sound practices for
developing safety-critical software. The disregard to the care of formal
documentation may yield better immediate gains, but ultimately degrades the
quality of the implementation, reusability of the software,  and traceability of
design decisions.

\subsection*{Cost}
While the actual materials and equipment necessary to implement this system are
of minimal cost (i.e. software development tools, database servers), the
man-hours spent in conforming to the proposed process model will increase.
Spending time collaborating with other developers and writing documentation
takes away from development time and will increase labor costs. If no negligence
dispute occurs, then the actual perceived saved costs may not be immediately
apparent. However, it can be argued that introducing our solution may have
prevented a negligence dispute from occurring in the first place, though 
concrete figures in actual time/money spent have yet to be researched. The key
drawback is that realizing the cost of this system is difficult to quantify.

\subsection{Future Work}
At the time of this paper's writing, the proposed system has yet to be
implemented. A proof-of-concept implementation should be built to confirm the
feasibility of the system. To overcome some of the system's drawbacks, we should
invest research into a cost/benefit analysis between time spent and money saved
if this system were to be adopted. In addition, it may be helpful to perform a
formal study, perhaps through industry opinion survey, to gauge the acceptance
of the system in real industry work.

That noted, the proposed system has a vast potential if accepted by the
industry. The key to this solution is its association database. Such a database
can be exploited to provide a richer feature set beyond the mere real-time
commenting capabilities of the proposed system. The automated techniques in 
\cite{Antoniol1999, Antoniol2000} could introduce the use of associated comments
to provide richer, more accurate associations. Annotations like those used in
\cite{Javadoc} can be introduced into associated comments to provide more formal
documentation formats with richer semantic metadata.

\subsection{Conclusions}
We have come up with a system that fulfills the role (at least partially) of the
archived evidence database mentioned in \cite{Turner2001}. In addition, we have
altered the software engineering process model for the development phase to help
integrate this system into the workflow of safety critical software development.

By introducing our system and process model into development phases, an
organization can more easily identify social responsibility in its engineers. In
addition, legal teams will be more actively involved in software development,
ensuring that safety constraints are met and adequate considerations are made in
case of a dispute.
